-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hardened compiler flags by default #12895
Conversation
By analyzing the blame information on this pull request, we identified @edolstra, @rbvermaa and @MarcWeber to be potential reviewers |
First off, awesome effort, thank you 👍 👍 👍 👍 🍻 Second, I know you say that it hasn't been tested on Darwin, but I'm wondering if you've tested things using the clang stdenv even on Linux. If so, I have reasonable confidence that all issues Darwin might encounter would be resolved ahead of time. Edit: is PIE off by default due to performance concerns? I believe on Mac OS, it's on by default for x86_64 due to it being cheap. |
Is there a global switch to turn this all off. Or should I be looking at clang? (For prototyping and boards like pie zero where I want speed, don't want the penalties this creates.) I would be interested in benchmarks to see what kind of a difference these changes make. |
Yes |
@globin cool tnx! |
@globin your evaluation error with |
There's no use for hardening during bootstrapping so you can selectively disable it in there. BTW, I didn't know gcc-4.8.3 is considered so old.
We've had an unresolved discussion around gcc5 switch due to the question whether to use the new C++ ABI by default (already). (Full conformance to C++11 vs. inability to link with stuff compiled by older gcc versions.) #8729 |
Hey, it was released over a year and a half ago. That's ages in computer time 😄 |
Ok sounds like I'll take the gcc bump out again. Regarding GCC 4.8:
|
Is moving to 4.9 less controversial than 5?
|
gcc49 is the default for the system, only the pre-built bootstrap gcc is at 4.8 |
@copumpkin PIE is off because it breaks nearly everything (see the Ubuntu link where they have turned it on), I reckon you're thinking of PIC. |
FYI, travis is saying:
|
👍 |
567043e
to
46b0d51
Compare
I just updated my
I also get the following the my dmesg (I'm using a grsecurity kernel):
This make sense to anyone here? |
@mrobbetts there was a bug in yesterdays commits. |
@globin ah, fabulous. Rebuilding now :) |
Is #17999 another such case? It is failing for me now. |
@edolstra, are you OK for us to merge |
The tests looked pretty good but the Golang ecosystem was broken by the If there are no objections (cc @edolstra) AND the latest eval looks clean (http://hydra.nixos.org/build/39336299#tabs-constituents), I will merge |
There are still 65 "newly failing jobs" compared to trunk-combined: http://hydra.nixos.org/eval/1289558?compare=trunk-combined |
But 97 newly succeeding Jobs 🙈 |
Agreed, unless @edolstra (or someone else) has concerns, let's go ahead and merge and deal with the minor remaining issues (which likely won't require a mass rebuild) in |
@domenkozar, are you concerned enough that you're saying we shouldn't merge? |
If you're willing to help fix those later (which I'm sure you do), let's merge if there are no objections from others. |
Looks great to me. Thanks for all the work on this! |
Great work guys, thanks :) |
https://gist.github.com/cleverca22/b1300b91ea6bf8951256c60acf2844ee __memcpy_chk appears to be missing from the libc.a in glibc.static master, but it is present on an older nixpkgs from 20f009d edit: |
Hmm, it seems we still have |
Thanks for pointing that out. We had to disable stackprotector for the glibc build but didn't investigate further. There are even more hardening options available in the configure script for glibc. I'll check what we can enable. Unfortunately, this will be another mass rebuild that probably won't make it into 16.09. |
Great work on this issue. Is there a way so that we can have these hardening flags applied to nixpkgs, but not always forcing gcc users to use the flags? See #18995 |
This adds some compiler/linker flags to harden our packages via a stdenv adapter:The following parameters are now available:
hardeningDisable
To disable specific hardening flags
hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
fortify
stackprotector
pie
(disabled by default)pic
strictoverflow
format
relro
bindnow
Information from the debian wiki:
Stack protector is a mainline GCC feature, which adds safety checks against stack overwrites. This renders many potential code injection attacks into aborting situations. In the best case this turns code injection vulnerabilities into denial of service or into non-issues (depending on the application). http://en.wikipedia.org/wiki/Stack-smashing_protection
Currently this uses-fstack-protector-all
instead of-fstack-protector-strong
because the bootstrapping compiler is too old.` /cc @edolstraFortify During code generation the compiler knows a great deal of information about buffer sizes (where possible), and attempts to replace insecure unlimited length buffer function calls with length-limited ones. This is especially useful for old, crufty code. Additionally, format strings in writable memory that contain '%n' are blocked. If an application depends on such a format string, it will need to be worked around.
Format
If -Wformat is specified, also warn about uses of format functions that represent possible security problems. At present, this warns about calls to printf and scanf functions where the format string is not a string literal and there are no format arguments, as in printf (foo);. This may be a security hole if the format string came from untrusted input and contains %n.
Position Independent Executable (pie) are needed to take advantage of Address Space Layout Randomization, supported by some kernel versions. While ASLR can already be enforced for data areas in the stack and heap (brk and mmap), the code areas must be compiled as position-independent. Shared libraries already do this (-fPIC), so they gain ASLR automatically, but binary .text regions need to be build PIE to gain ASLR. When this happens, ROP attacks are much harder since there are no static locations to bounce off of during a memory corruption attack.
relro
During program load, several ELF memory sections need to be written to by the linker, but can be turned read-only before turning over control to the program. This prevents some GOT (and .dtors) overwrite attacks, but at least the part of the GOT used by the dynamic linker (.got.plt) is still vulnerable.
bindnow
During program load, all dynamic symbols are resolved, allowing for the complete GOT to be marked read-only (due to -z relro above). This prevents GOT overwrite attacks. For very large application, this can incur some performance loss during initial load while symbols are resolved, but this shouldn't be an issue for daemons.
State in other Distributions
Nearly all major distributions are setting these flags by default (except for pie), debian started working on this ~10 years ago, see links at the end.
Most packages build (https://hydra.nixos.org/jobset/nixpkgs/pr-12895#tabs-evaluations), mostly needs further testing at runtime.
I'd be happy to hear more comments, ideas, concerns!
Links
https://wiki.debian.org/Hardening
https://wiki.ubuntu.com/Security/Features
https://wiki.gentoo.org/wiki/Project:Hardened (and https://wiki.gentoo.org/wiki/Hardened/FAQ)
https://wiki.archlinux.org/index.php/DeveloperWiki:Security
(/cc @copumpkin @fpletz)